These notes are much more important in an open community like OpenCPN. Otherwise work issues tend to be stored out of sight and we risk two or more are working on the same thing clueless of each others. Open cooperation and problem solving communication is a better way.
There is a wide range of skills & skill levels in this community. We all try to help each other, but we need to understand that this is all voluntary, and intended to be fun. We all share the common interest of supporting and creating great Chart Plotter Navigation software.
We unfortunately don't have manpower to teach people programming and duplicate every piece of documentation out there.
Dave has suggested these websites for Training in C++ which is the most basic skill required. In any case they should be bookmarked and studied.
We also do not have energy, time, resources, whatever, to maintain the outdated toolchain, dependencies and know-how.
However all the build instructions are updated for the current master and that is what developers should use. Version 4.8.2 is history. (Pavel -Nohal)
There are many ways to participate in and assist this Open Source Project. Many different skills and efforts are needed.
Language Translation: Assist by Crowdin Translation of OpenCPN and Plugins
User Manual: Assist by Editing
User Feedback: Suggestions, User Interface Suggestions, Feature Requests, Bugs
should be done exclusively via:
Note:
Beta Testing is conducted in a Real Time environment (not using Debug) by volunteer testers or end users when the development team determines the software is ready.
Any user can be a beta tester, they need to know how to install and use the software and report. Using CI tools is inappropriate for Beta Testing.
Done early on by skilled testers at the specific request of programmers who are actively creating big new features or internal optimizations. These skilled testers are asked by the programmers to help achieve the main goals of the program to get it ready for Beta Testing, using a “Debug” environment. They do not “Bug” the programmers with:
They debug the program using their software tools and report the actions and error codes using MSVC++ call stack, or Linux debug tools. Beta testing can only begin when the development team is sure there are no obvious bugs such as null pointer deref or other errors that can be caught through testing inside a debug environment. Beta testing begins when the development team wishes it.
Sometimes called “heat-seekers”. For this type of tester, using the CI products for informal alpha testing of unreleased code is very useful to the devs. The main benefit to devs is the rapid cross-platform exercise of the app, where testers bang away on the interface using their favorite workflows, and attempt to break it. Most devs don't keep current images of all 5 platforms available for extended testing, and in any case this takes a lot of time. However with the software tools below, the time spent compiling is dramatically less.
It simply must be understood that this alpha testing is ad-hoc, and is not tracked in any persistent manner. But it does advance the code-base integrity quickly.
However do not “bug” the programmers. Simply report your findings as completely as possible using the Github “Issues” section. Include any pertinent logs, screenshots or files. Do not combine issues into one post and identify the program version or date.
Programming skills vary greatly. Some are learning, some have many years of experience.
Debugging see the “Compiling” pages“
Online Repositories - Free to Opensource
Additional Software Tools which integrate with and push to Github - Free to OpenSource :
Further reading: AppVeyor - A good continuous integration system is a joy to behold